Next | Prev | Up | Top | Contents | Index

Multiprocessor Issues

Prior to IRIX 5.3, the kernel BSD framework code and TCP/IP protocol executed under a single kernel lock on multiprocessor systems making it a single-threaded implementation. In IRIX 5.3, the BSD framework and TCP/IP protocol suite have been multi-threaded to support symmetric multiprocessing by the addition of kernel locks protecting critical sections. It now supports multiple, concurrent threads of execution within the TCP/UDP/IP protocol suite, kernel socket layer, and bundled networking device drivers.

These changes are transparent to user-level programs, but, if you've written your own ifnet-based networking driver, it requires minor source-level changes in order to run in IRIX 5.3.

In a multi-threaded kernel, raising the processor interrupt level (IPL) by calling one of the spl routines, such as splimp() or splnet(), blocks interrupts from occurring on the local processor; it does not prevent interrupts from occurring on other processors in the system, nor does it prevent other processes on other processors from executing code in your critical section.

Under BSD networking, drivers interface with the protocol stacks by queueing the incoming packets on a per-protocol input queue. On multiprocessor systems, this protocol input queue must be protected by the locking macros defined in the file net/if.h.

All the locking macros that protect the input queue are assumed to be called at the proper processor masking level, splimp. All input queue locking macros also take an input parameter ifq, which is a pointer to the protocol input queue that must be defined as a struct ifqueue.


Next | Prev | Up | Top | Contents | Index